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PROCEDE DE DETERMINATION DE CARACTERISTIOUES 
OPERATIONNELLES D'UN PROGRAMME, 

10 La presente invention a pour objet un procedd pour la determination de 
caracteristiques operationnelles d'un programme. 

Elle s'applique notamment a la validation d' applications par rapport k des 
criteres operationnels sp^ciflques donnes et, en particulier, a Pautomatisation 
15 du controle du programme en vue de son execution sur des plates-formes 
cibles par des utilisateurs donnes. 

L' invention concerne egalement un systeme mettant en oeuvre le proc^de selon 
T invention pour garantir que des applications proposees par un serveur 
20 respectent des criteres de validite associes aux plates-formes d'ex^cution de 
ces applications. 

La plupart des petits systemes embarques (terminaux de paiement, organiseurs 
electroniques, telephones mobiles, cartes a puce, etc.), realises il y a quelques 
25 annees, etaient des systemes ferm^s ne pouvant executer que des programmes 
determines installes lors de la fabrication. De meme, bien que 
fonctionnellement plus ouverts, la plupart des ordinateurs etaient d6connect£s 
de tout reseau et les quelques programmes qu'ils ex^cutaient avaient pour 
origine des editeurs de logiciels bien identifies. Du fait de cette faible 
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variability il etait alors possible de « contenir » les defauts de fonctionnement 
des plates-formes d' execution et des programmes. 

Aujourd'hui, la tendance est a l'ouverture des petits systemes embarqu£s : 
meme si la maitrise n'en revient pas toujours directement a Putilisateur final, 
5 on peut desormais charger de nouveaux programmes sur ces plates-formes 
d'execution. Par ailleurs, beaucoup d'ordinateurs et de systemes embarques 
sont connectes, temporairement ou non, a des reseaux (Internet, telephonie 
mobile, etc.) sur lesquels sont telecharges des programmes aux origines 
souvent inconnues et aux fonctionnalites souvent indeterminees. Enfin, la 
10 segmentation des marches et la multiplication des fournisseurs, des modeles 
materiels et des versions logicielles conduisent, malgre la definition de 
standards, a des combinaisons de configurations qui n'ont pas toujours ete 
anticipees. Cette situation accentue les risques de dysfonctionnement, 
notamment en ce qui concerne la s^curite et rinteroperabilite. 

15 

Volontaires ou involontaires, les dysfonctionnements d'une application 
concernent en premier chef la securite. Une application peut par exemple 
effectuer des operations illicites (divulguer un code secret, se connecter a des 
sites non autorises, effectuer silencieusement des envois de messages, etc.), 
20 effectuer des operations licites mais pour lesquelles elle n'a pas les droits 
approprtes, consommer plus de ressources que ce a quoi elle peut pretendre et 
ainsi en priver d'autres applications, alterer des donnees precieuses, etc. 

Un autre souci majeur concerne rinteroperabilite. En effet, une application 
25 peut faire appel a des fonctionnalites mat6rielles ou logicielles qui s'avSrent ne 
pas etre presentes sur la plate-forme d' execution (par exemple parce qu'elles 
sont optionnelles ou limitees) ou qui sont presentes d'une maniere inattendue 
(par exemple a cause d'une incompatibilite de version). Dans ce cas, 
l'application ne fonctionne pas ou fonctionne mal, ce que l'utilisateur final 
30 peut imputer h tort au fournisseur du service ou du materiel. 
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Les consequences de ces dysfonctionnements peuvent etre tres graves dans le 
cas de systemes critiques ou la securite est primordiale. C'est le cas par 
exemple pour les applications dans le domaine de la banque, de la sant£, du 
transport, de Pidentite, etc. Meme lorsque les dysfonctionnements sont 
5 mineurs pour les utilisateurs et ne se soldent que par de faibles d£gats ou des 
indisponibilites des systemes, les retombees commerciales peuvent etre 
desastreuses pour les fournisseurs de materiel ou de logiciels : non seulement 
cela peut necessiter de couteux rappels de materiel, mais surtout cela peut 
endommager leur image aupres des consommateurs. Le risque est notamment 
10 manifeste pour les op^rateurs telephoniques qui permettent a leurs utilisateurs 
de telecharger de nouveaux programmes dans leurs telephones mobiles. 

Outre les problSmes de securite et d' interoperability, certains fournisseurs 
veulent aussi appliquer une discipline de ddontologie (par exemple, pour le 
15 controle d'acces des mineurs), des principes d'ergonomie ou des regies de 
style (par exemple, pour le respect d'un « Look and Feel »). 

Le probleme qui se pose est en fait plus generalement celui du controle de 
T adequation d'un programme a une certaine « politique » de securite, 
20 d' interoperability, etc. 

Avant de r£pondre k la question du controle des programmes, une premiere 
etape consiste tout d'abord a etablir des criteres qui definissent s'il est 
acceptable ou non qu'un programme donne soit execute sur une plate-forme 

25 cible donnee (ou un ensemble de plates-formes) par certains groupes 
d'utilisateurs donnas. Des criteres de security peuvent notamment etre issus 
d'une analyse de risque prealable, qui evalue notamment les biens a proteger 
sur la plate-forme et dans les programmes, les menaces a Pencontre de ces 
biens, et les mesures a prendre pour s'en premunir. Des criteres 

30 d' interoperability peuvent etre tires des cas d'erreur signales par les equipes de 
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test et les utilisateurs, ainsi que de 1' experience de bonne programmation des 
developpeurs. 

Par exemple, dans le cas d' application pour cartes a puce, un critere securitaire 
5 peut stipuler qu'il est interdit d'utiliser des cles « DES » trop faibles, par 
exemple d'une longueur inferieure a 128 bits. De meme, un critere 
d'interoperabilite peut stipuler de ne pas utiliser de c\6 « RSA », ou de cles 
« RSA » de longueur superieure a 1024 bits, parce que la plate-forme cible ne 
permet pas de manipuler ce type de cl6s, ou des cl6s d'une telle taille. 

10 

Pour pouvoir etre verifies de maniere non ambigue, les criteres doivent etre 
clairement formulas. Un critere s'exprime souvent sous forme de contraintes 
concernant l'usage de routines ou classes de librairies. Dans le cas 
d' applications « Java Card » (langage qui est specialise pour Texecution sur 

15 une carte a puce), Texemple de critere securitaire ci-dessus s'exprime de 
maniere plus explicite par : « La methode « buildKey(keyType, keyLength, 
„.)» n'est pas appelee avec un argument « keyLength » inferieur a 128 si 
l'argument « keyType » est egal a la valeur de la constante « TYPE_DES » ». 
(« Java » et « Java Card » sont des marques d6pos6es de Sun Microsystems. 

20 Pour des raisons de Hsibilit6, le prefixe de classe 
« javacard.fr amework.KeyBuilder » sera volontairement omis). 

Ainsi le programme suivant satisfait-il le critere securitaire : 
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"void install(byte[] buf, short ofs, short len) { 

switch(buf[ofs++]) { 

case 1: // Use DES 128 bits 
5 myKey = buildKey(TYPE_DES, LENGTH_DES3_2KEY); 

break; 

case 2: // Use DES 192 bits 

myKey = buildKey(TYPE_DES, LENGTH_DES3_3KEY); 
break; 

1 0 case 3 : // Use RSA 1 024 bits 

myKey = buildKey(TYPE_RSA_PRIVATE, LENGTH RS A_ 1 024) ; 
break; 

} 

15 } 

En effet, quels que soient les chemins d' execution, la m^thode «buildKey » 
est toujours appelee avec des arguments compatibles avec le critere : ou bien 
« key Type » vaut « TYPEDES » et « keyLength » vaut 
20 « LENGTH DES3 2KEY » (egal a 128) ou « LENGTHDES33KEY » 
(egal a 196), ou bien « keyType » vaut « TYPERSAPRIVATE » (different 
de « TYPEJ3ES »). 

En revanche, le programme suivant ne satisfait pas le critere. 
25 void install(byte[] buf, short ofs, short len) { 

myKey = buildKey(buf[ofs++], buf[ofs++]); 
f 

30 

En effet, la valeur « buf » est un argument dynamique : il est done possible de 
construire des cles de type et de longueur arbitraire. En particulier, il est done 
possible que « buflofs] » soit egal k « TYPE_DES » et que « buf[ofs+l] » soit 
inf^rieur a 128. 

35 

En ce qui concerne le controle effectif d'un programme, T6tat de Part peut se 
resumer comme suit : 
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Pour determiner si un programme donne satisfait des criteres donnes pour une 
plate-forme donn£e, plusieurs approches sont aujourd'hui employees. Elles se 
distinguent selon plusieurs aspects : le controle est statique (avant P execution 
sur la plate-forme) ou dynamique (pendant P execution) ; le controle est « boite 
5 noire » (sans regarder le code) ou « boite blanche » (en regardant le code) ; le 
controle est « manuel » (sans Paide d'outils d' analyse) ou automatique (avec 
Paide d'un outil d'analyse). Les controles couramment employes sont les 
suivants : 



10 • Les criteres, notamment securitaires, peuvent etre mis en oeuvre par des 
controles dynamiques effectues au cours de F execution du programme. 
Cette approche a trois desavantages majeurs. Tout d'abord, elle d6couvre 
les problemes trop tard, une fois le programme deja charge et en cours 
d'execution. Ensuite, parce qu'elle n'a qu'une vision « boite noire » de 

15 P application, elle necessite de borner arbitrairement Fexploitation des 

fonctionnalites et ressources de la plate- forme (par exemple, pas d' envoi 
de plus de trois messages). Enfin, elle ne resout pas les problemes 
d'interoperabilite. 



20 • Le programme peut aussi etre teste en boite noire, sans regarder le code. 

Avec cette approche, le programme est execute dans un certain nombre de 
circonstances supposees representatives, et son comportement est observe 
de Fext6rieur pour juger s'il respecte les criteres. Cette solution peut 
permettre de repondre a certaines questions liees a Fergonomie, mais ne 

25 procure pas de garantie forte sur les questions de securite ou 
d'interoperabilite. En effet, on n 9 examine avec cette methode qu'un petit 
nombre de chemins d' execution possibles, alors qu'il en existe une infinite. 
Par exemple, des chevaux de Troie (programme ou donnees qui semblent 
inoffensives lorsqu'elles sont chargdes sur la plate-forme mais qui facilitent 

30 ensuite une attaque, par exemple par un pirate ou un virus) ne peuvent etre 
detectes a coup sur. 
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• Le programme peut etre controle manuellement, en regardant le code mais 
sans Faide d'un outil d'analyse. Cette solution a de nombreux 
desavantages. Un tel controle est en effet long (done couteux) et fastidieux, 

5 ce qui interdit en pratique le traitement de gros volumes de programmes. 
De plus, il faut repayer le cout du controle a chaque nouvelle version du 
programme, de la plate-forme d' execution ou des criteres. Par ailleurs, 
cette approche suppose en pratique que le code source du programme est 
disponible, ce qui est peu souvent le cas pour des raisons de confidentialite 
10 ou de propriete industrielle. Lorsque seul le code objet est disponible, 
F analyse manuelle devient extremement longue et difficile, et le risque 
d'une erreur humaine est multiplie d'autant. 

• Le programme peut aussi etre controle automatiquement, avec Faide d'un 
15 outil d'analyse. Plusieurs types d'outil existent aujourd'hui : 

- Certains outils verifient a Faide d'une analyse statique que le code d'un 
programme respecte des regies generates de bonne formation et de bon 
typage, ce qui apporte certaines garanties de bon fonctionnement, quelle 

20 que soit la plate-forme cible. C'est par exemple le cas des verificateurs de 
code octet (« bytecode verifiers ») associes aux environnements d' execution 
« Java », y compris « Java Card ». De tels analyseurs de types peuvent 
fonctionner aussi bien sur le code source que sur le code objet. lis ne 
repondent toutefois pas a des criteres particuliers, concernant par exemple 

25 la securite ou Finterop6rabilite. 

- D'autres outils, surtout destines aux developpeurs, verifient a Faide d'une 
analyse statique que le code d'un programme ne peut pas effectuer 
d' operations qui n'ont pas de sens, comme de dereferencer un pointeur nul 

30 ou acceder a un element de tableau hors des limites. Ces outils apportent 
ainsi certaines garanties de bon fonctionnement, quelle que soit la plate- 
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forme cible. Mais comme pour les analyseurs de type, ils ne repondent pas a 
des criteres parti culiers. 



- Enfin, certains outils examinent le code du programme, source ou objet, 
5 pour rechercher des occurrences d'appels de routines. Ils permettent ainsi 
d'appliquer des criteres specifiques qui interdisent V usage de certaines 
routines (que ce soit pour des raisons de securite ou d'interoperabilite) : ils 
rejettent tout programme qui comportent des appels a ces routines. 
Cependant, de tels outils ne peuvent pas non plus verifier le genre de regie 
10 donne en exemple ci-dessus : il faut non seulement detecter que la methode 
« buildKey » est appelee mais aussi savoir si son premier argument est egal 
a « TYPEDES » et son deuxieme argument inferieur a 128. 



Compte tenu des problemes precedemment evoques, T invention a plus 
15 particulierement pour but de permettre le developpement d'outils de controle 
qui peuvent d' adapter aux besoins de regies specifiques tout en permettant la 
verification automatique de regies complexes, concernant notamment la valeur 
possible des arguments de certaines operations et l'enchainement de telles 
operations. 

20 

A cet effet, elle propose un procede pour la determination de caracteristiques 
operationnelles d'un programme mettant en ceuvre une procedure de 
verification comportant les etapes suivantes : 



25 - une premiere etape comportant : 

■ F expression des caracteristiques operationnelles du programme comme 
des fonctions portant sur des occurrences ou des sequences 
d 5 occurrences d'ev^nements pouvant se produire au cours des 
executions possibles du programme, lesdits evenements pouvant porter 

30 sur des operations particulieres, sur des valeurs parti culieres, en des 
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points de programme particuliers et dans des etats particuliers du 
programme ; 

■ la determination d'un degre de precision eventuel avec lequel ces 
caracteristiques doivent etre determinees ; 

5 "la determination d'un ensemble 6ventuel de contextes d'execution 
particuliers dans lesquels le programme sera toujours execute ; 

■ la determination de specificites operatoires eventuelles d'un ensemble 
de plates-formes sur lesquelles le programme sera execute ; 

10 - une deuxieme etape d' estimation, par des analyses de programme, et en 
tenant compte dudit degr£ de precision eventuel, dudit ensemble eventuel 
de contextes d'execution particuliers et desdites specificites operatoires 
eventuelles de plates-formes, d' informations concernant la structure du 
programme, les chemins d'execution possibles du programme et les 

15 valeurs de donnees possibles, en divers points des chemins d'execution et 

sous differentes conditions d'execution, des etats et donnees manipulees 
par le programme ; 

- une troisidme etape de determination desdites caracteristiques 
20 operationnelles, grace aux informations extraites par lesdites analyses de 

programme, par le calcul desdites fonctions sur les occurrences ou 
sequences particulieres d' occurrences d' operations particulieres, portant 
sur des valeurs particulieres, en des points de programme particuliers, dans 
des etats particuliers du programme, pour 1' ensemble des chemins 
25 d'execution determine par les analyses. 

Ce proc£d£ pourra prendre en compte : 

- un ensemble de caracteristiques concernant les operations que le 
30 programme peut effectuer au cours de son execution. 



WO 2005/073860 PCT/FR2004/003394 

10 

Avantageusement, les informations extraites au cours de la deuxieme etape du 
procede pourront etre representees a l'aide d'une ou plusieurs des structures 
suivantes : graphe d'etat du programme, graphe d'heritage, graphe d'appel des 
routines du programme, graphe de flot de controle de chaque routine du 
5 programme, structure de boucles et de rattrapage d' exceptions, structure de 
blocs de base (« basic blocks »), abstraction de Tetat du programme en un 
point d' execution, etant entendu que : 

- ladite extraction d 5 informations ne porte pas sur des informations inutiles a 
10 la determination des caracteristiques operationnelles, tant du point de vue 

de la quantity d' informations extraites que de la precision de ces 
informations, 

- les informations majeures parmi lesdites informations extraites sont 
calculees et stock£es, tandis que les autres informations ne sont calculees 

15 que lorsque necessaire pour la determination desdites caracteristiques 

operationnelles. 

Par « information majeure », on entend les informations extraites aux noeuds 
d'une decomposition du code des routines en un graphe de blocs de base 
20 (« basic blocks »), les autres informations (dans le corps des blocs de base) 
etant recalculees par une analyse locale a partir des informations stockees en 
debut et en fin de bloc correspondant. 

II apparait clairement que ce procede peut etre mis en oeuvre pour realiser un 
25 systeme d'execution multi applications garantissant que les applications 
respectent des criteres de validite donnes. 

L'invention s'applique en outre au filtrage automatique d'un ensemble de 
programmes par rapport a un ensemble de criteres de validite donnas. Dans ce 
30 cas, les susdites caracteristiques operationnelles repr£sentent des criteres de 
validity. L' etape de determination etablit alors soit que le programme est 
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valide parce qu'il respecte chacun desdits criteres ou invalide parce qu'au 
moins Tun desdits criteres ne peut pas etre respecte. 

Les trois etapes de la procedure de verification mises en oeuvre par le procedS 
5 selon F invention seront decrites plus en detail ci-apres, a titre d' exemple non 
limitatif. 

Expression des criteres : 

10 Dans un premier temps, les criteres sont traduits en termes d' evenements 
definis comme la realisation d' operations particulieres portant sur des valeurs 
particulieres en des points de programme particuliers. A titre d'exemple, 
certaines desdites operations particulieres (qui, accompagnees de contraintes 
sur les valeurs manipulees, les points d' execution, et les etats du programme, 

15 forment des evenements) sont d6finies comme Fune des actions suivantes : 
appel a une routine donnee, acces a une variable donnee, lecture ou ecriture 
sur un port donne, calcul d'une expression arithm&ique donnee, fin 
d 5 execution du programme ou d'une routine (sur un retour normal ou une 
levee d'exception). 

20 

Un evenement est par exemple F appel a une routine avec un argument a 
Finterieur d'un certain intervalle (cf. exemple ci-dessus concernant Fappel a la 
methode « buildKey » avec un argument infSrieur a 128), Facets a un element 
de tableau k un certain indice, le fait que les arguments d'une addition sont tels 
25 que Faddition peut ddborder, Fatteignabilit6 d'un point de programme sous 
une condition symbolique portant sur les valeurs manipulees par le 
programme, le fait que le programme ou une routine termine dans un etat 
particulier en levant une exception particuliere, etc. 

30 Un critdre meme s'exprime comme une fonction qui porte sur les occurrences 
ou sequences particulieres d'occurrences de tels evenements, au cours des 
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diverses executions possibles du programme. On peut ainsi modeliser des 
criteres relativement complexes. 

Un cadre possible pour F expression formelle de tels critdres est la logique 
5 temporelle lineaire (LTL). Ce formalisme permet d'exprimer par exemple que 
des evenements se produisent toujours, ou bien tot ou tard, ou bien qu'une 
condition reste vraie jusqu'a ce qu'un evenement se produise, etc. 

Par exemple, « Java Card » fournit une aide specifique pour realiser une 
10 transaction (mise a jour atomique de Fetat permanent du systeme). Pour cela, 
il faut appeler la methode « beginTransactionQ », effectuer des mises a jour, 
puis appeler la methode « commitTransaction() ». On est alors garanti qu'en 
cas de remise a jour (notamment intempestive) de la carte, soit aucune 
modification n'aura effectuee, soit toutes les modifications n'auront ete 
15 effectives. Le critere de validity des transactions stipule notamment que la 
methode « commitTransaction() » ne doit etre appelee qu'apres Fappel de 
« beginTransaction() ». 



Les sequences d' evenements peuvent aussi faire intervenir les valeurs 
20 manipulees par le programme. Par exemple, si un critere stipule qu'on ne peut 
pas liberer une ressource sans F avoir auparavant allouee — sinon la liberation 
echouerait — , on peut definir une regie explicite du type suivant : une routine 
donn6e (par exemple de liberation de ressource) ne peut etre appelee avec un 
certain argument que si cet argument a ete la valeur de retour d'une autre 
25 routine donnee (par exemple d' allocation de ressource) appelee 
prec^demment. Un tel exemple dans F implementation « Java Card » de la 
specification « Open Platform v2.0.T » est donne par la methode de fermeture 
de canal s^curise (« closeSecureChannel »), qui doit etre appelee avec comme 
argument la valeur de retour de la methode d'ouverture de canal securise 
30 (« openSecureChannel »). Le programme suivant est invalide en ce sens : 
void process(APDU apdu) { 
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chanNum = openSecureChannel(apdu); 

closeSecureChannel(O); 
5 ... 

} 

En effet, pour que ce programme soit valide, il faudrait que la fermeture du 
canal securise s'effectue par « closeSecureChannel(chanNum) ». De fait, ce 
10 programme ne fonctionne que dans le cas ou la methode 
« openSecureChannel » retoume la valeur 0. 

On peut aussi par exemple vouloir s'assurer que des traitements specifiques 
doivent necessairement etre prevus pour un ensemble de circonstances 

15 particulieres. Un critere assocte peut par exemple s'exprimer par la regie 
suivante : pour toute valeur d'un argument donnee d'une routine donnee (par 
exemple d'enregistrement de 1'application aux interruptions ou evenements 
programmatiques designes par cet argument), il existe du code d'une autre 
routine donnee (par exemple de traitement des interruptions ou evenements 

20 programmatiques auxquels V application est abonnee) qui est uniquement 
atteignable lorsque cette autre routine est appelee avec en argument ladite 
valeur. 

La traduction des criteres en terme de regies explicites ainsi formul6es peut 
25 s'effectuer une fois pour toute, tant que les criteres restent les memes. Sauf 
dans le cas particulier de criteres dependant d'une specification ou d'une 
implementation de programme donnee, la traduction est en effet independante 
des programmes. 

30 Extraction d' informations par analyses de programme : 

Dans un deuxieme temps, pour un programme donne, des analyses statiques 
extraient des informations concernant la structure du programme, les chemins 
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d'execution possibles du programme et les valeurs possibles, sous differentes 
conditions d' execution, des donnees manipulees en divers points des chemins 
d' execution. 

5 II existe un ensemble de techniques connues pour determiner des informations 
sur les chemins d' execution possible du programme. Ces techniques 
permettent de calculer notamment le graphe d'appel des routines du 
programme et, pour chaque routine, son graphe de flot de controle (dont les 
noeuds sont regroup6s ou non dans des blocs de bases) et sa structure de 
10 boucles et de rattrapage d' exceptions. Ces diverses structures de donnees sont 
des expressions finies et regulieres qui peuvent representer en fait une infinite 
de chemins d' execution et qui forment un surensemble (pour des raisons 
d' approximation expliquees ci-dessous) de 1' ensemble de tous les chemins 
d' execution possibles du programme. 

15 

II existe egalement des techniques, notamment T interpretation abstraite, qui 
permettent d'obtenir des valeurs approch^es (par exemple, des ensembles de 
valeurs possibles) des donnees manipulees par le programme en divers points 
d' execution du code. Ce type d' information est ordinairement calculi afin de 

20 detecter des operations elementaires qui risquent d'echouer, comme la 
dereference d'un pointeur nul ou Tacces a un element de tableau hors de ses 
limites. Mais T interpretation abstraite est plus generate. Elle peut notamment 
manipuler des valeurs symboliques et ainsi determiner les conditions abstraites 
associees aux divers chemins d'exdcutions que le programme peut emprunter. 

25 Cela permet par exemple de savoir, comme dans T exemple des traitements 
specifiques ci-dessus, si un point de programme est uniquement atteignable 
sous une condition particuliere, donn^e ou calculee. 

D'autres elements d' architecture du programme, comme le graphe d'heritage 
30 (exprimant la hierarchie de classes dans le cas des langages a objets), peuvent 
aussi etre determines. 



WO 2005/073860 



15 



PCT/FR2004/003394 



Determination du respect des criteres : 

Dans un troisieme et dernier temps, les criteres sont evalues sur les 
5 informations extraites par les analyses. Autrement dit, les fonctions associees 
aux criteres sont 6valuees en considerant, pour V ensemble des chemins 
d' execution possibles calcules, les occurrences ou sequences particulieres 
d'evenements constitues par la realisation d' operations particulieres en des 
points de programme particuliers et portant sur des valeurs particulieres. La 
10 nature effective des calculs depend de la formulation des criteres et des types 
d 9 informations extraites par les analyses. 

De nombreux perfectionnements de T invention peuvent etre constants sur la 
base de la procedure decrite ci-dessus. Des exemples de tels 
15 perfectionnements, qui sont combinables les uns avec les autres, seront decrits 
individuellement ci-apres. 

Param&risation de la precision : 

20 On observera tout d'abord que, dans le cas general, les chemins d' execution et 
les valeurs manipul£es par le programme correspondent a des proprietes 
mathematiques dites indecidables : on ne peut pas les determiner avec 
exactitude mais on peut toutefois les approcher. En pratique, cela signifie 
qu'on ne peut connaitre les chemins et les valeurs manipulees qu'avec une 

25 precision limine. 

Or il est souvent primordial que ces informations soient determines avec une 
grande precision. Dans le cas contraire, on peut signaler qu'un critere (par 
exemple qui impose qu'une quantity soit positive) risque de ne pas etre 
30 respecte (par exemple parce qu'on a pu seulement determiner que cette 
quantite pouvait etre comprise entre -10 et 30) alors qu'une meilleure 
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precision d' analyse (par exemple qui determinerait que cette quantite ne peut 
en fait qu'etre comprise entre 5 et 20) aurait permis de conclure que le critere 
est toujours respecte. 

5 En l'absence d'une precision suffisante, il faut soit rejeter F application « par 
securite » (au risque de rejeter une application inoffensive), soit controler 
manuellement les criteres sur lesquels Tanalyse automatique n'a pu conclure. 
En cas d'analyse manuelle, on peut beneficier des informations extraites par 
T analyse qui, bien que pas suffisamment precises, permettent souvent 
10 neanmoins de circonscrire le perim&tre de la verification. 

Dans tous les cas, il est avantageux de permettre une param^trisation de la 
precision avec laquelle on effectue lesdites analyses. Ce parametrage peut 
concerner les domaines de valeurs abstraites. Par exemple, les valeurs entieres 

15 peuvent etre abstraites par des valeurs exactes (ou la valeur indeterminee) ou 
par des intervalles. De meme, les references peuvent etre abstraites par leur 
type ; les tableaux, par une indication de leur longueur ; les chaines de 
caracteres, par une indication du prefixe connu (eventuellement vide) de la 
chaine, etc. Le parametrage peut aussi concerner les points de fusion de 

20 valeurs au cours de V interpretation abstraite : analyse sensible au point de 
programme ou non, analyse mono-procedurale ou inter-procedurale, analyse 
sensible au contexte ou non, etc. 

Execution du programme dans des contextes particuliers : 

25 

Par ailleurs, quelle que soit la precision de V analyse, les valeurs approchees 
des donnees manipul^es sont des proprtetes du programme qui sont vraies 
pour toutes les executions possibles du programme, c'est-a-dire quels que 
soient ses arguments d' entree. Or il est des cas ou Ton sait que le programme 
30 ne sera utilise que d'une certaine maniere, dans certains contextes, c'est-a-dire 
avec des contraintes connues concernant ses arguments. 



WO 2005/073860 



17 



PCT/FR2004/003394 



En cette circonstance, on peut am&iorer la precision de T analyse en prenant 
en compte des hypotheses sur les valeurs de ces arguments. Dans le cas d'une 
analyse pas interpretation abstraite, au lieu de supposer tous les arguments 
5 indetermin^s, on peut notamment donner des valeurs abstraites particulieres 
aux parametres (y compris de configuration) et arguments du programme 
avant de lancer F analyse. 

Calculs reduits aux informations necessaires : 

10 

Outre la precision des informations calculees, la quantite de ces informations 
est aussi un parametre sur lequel on peut jouer. En particulier, il n'est pas 
necessaire qu'une analyse de programme determine toutes les valeurs 
manipulees en tous les points de programme. En effet, seules les informations 
15 qui interviennent dans les formules qui represented les crit£res n'ont a etre 
calculees et memorisees lors des analyses. 

Pour reduire encore davantage la quantity d' informations stockees, on peut 
aussi ne m^moriser des informations qu'en certains points critiques et 

20 recalculer les informations manquantes selon les besoins de revaluation des 
criteres. Par exemple, on peut ne memoriser les informations qu'aux noeuds 
d'une decomposition du code des routines en un graphe de blocs de bases 
(« basic blocks ») ; lorsqu'une information est necessaire en un point de 
programme quelconque d'un bloc de base, elle peut aisement etre recalculee 

25 par une simple analyse locale k partir des informations stock6es en debut et fin 
de bloc. 

Ces optimisations reduisent les ressources (espace memoire, temps de calcul) 
necessaires pour la mise en ceuvre de la procedure de verification. A 
30 ressources constantes, ces optimisations permettent aussi une meilleure 
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precision, et done une reduction ou disparition des eventuelles verifications 
manuelles additionnelles. 



Calculs d' informations et evaluation des criteres simultan6s : 

5 

Dans le meme esprit de reduction des ressources consommees, certains 
criteres peuvent aussi etre evaluds au vol, au cours des analyses de 
programmes. En combinant, au moins pour certains criteres, les deuxieme et 
troisieme Stapes de la procedure de verification, on evite un stockage massif 
10 d' informations, meme temporaire : T information est consommee des qu'elle 
est produite, et ensuite peut etre oubliee. 



Verification de programmes interactifs : 



15 Par ailleurs, la procedure decrite ci-dessus peut etre appliquee a un programme 
interactif, e'est-^-dire a un programme qui depend d'un nombre indetermin^ 
de valeurs dynamiques externes resultant de cette interaction. Un tel 
programme peut en effet etre vu comme un programme qui lit 
progressivement des suites de donnees, eventuellement infinies (les contextes 

20 d 5 execution sont donnes ici par une description abstraite des suites de donnees 
possibles representant lesdites valeurs dynamiques). Ces suites de donnees 
peuvent etre modelis£es par des valeurs abstraites finies au meme titre que les 
autres arguments du programme, pour les besoins des analyses statiques. 



25 Verification de programmes dans des cadres d'execution : 



De plus, dans certains cas, une partie de la logique du programme peut etre 
geree par un cadre d' execution (« framework »), implements sur les plates- 
formes. Par exemple, les applications « Java Card » s'inscrivent dans un tel 
30 cadre. Une application « Java Card » doit notamment h£riter de la classe 
« javacard.framework. Applet » et definir deux methodes : « installQ » et 
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«process()». L'ex£cution du programme consiste en r appel par la plate- 
forme de la methode « install() » avec en argument un tableau d' octets, puis 
(en omettant pour simplifier la question de la selection) en un nombre 
ind&ermine d' appels de la methode «process()» avec, h chaque appel, un 
5 nouveau tableau d' octets en argument. (On peut remarquer que les 
applications « Java Card » sont ainsi egalement des programmes interactifs au 
sens indique ci-dessus). 

Pour appliquer la procedure decrite ci-dessus a de tels programmes, il faut 
10 aussi prendre en compte le cadre d' execution. Dans Texemple de « Java 
Card », cela peut conduire a rendre explicite pour les analyses la boucle qui est 
implicite dans le cadre d'exScution, qui effectue les appels de la methode 
« process() ». 

15 Les analyses statistiques pourront prendre en compte la semantique de ce 
cadre d' execution (y compris les eventuelles boucles d'interaction implicites 
du programme). 

Graphe d'etats : 

20 

Pour augmenter la precision des analyses, il est aussi parfois necessaire de 
« derouler » les boucles et appels recursifs du programme en fonction 
d' informations concernant les valeurs manipulees par le programme a 
I' execution. On obtient ainsi non pas des informations globales qui sont vraies 

25 quel que soit le nombre d' iterations d'une boucle ou d 5 appels recursifs, mais 
des informations locales, pour chaque tour de boucle ou appel recursif. Ce cas 
figure se produit notamment dans le cas de programmes interactifs qui 
s'inserent dans des cadres d'execution. Par exemple, dans le cas d'une 
application « Java Card », les appels successifs a la methode « process() » 

30 peuvent conduire k des resultats d' analyse differents en fonctions des etats du 
programme calculus lors des appels precedents. 
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L'analyse de l'application, apres d6roulage de la boucle d'interaction implicite 
ainsi que abstraction et identification des etats du programme, fournit alors 
comme resultat un graphe d' etats sur lequel peuvent etre calcules les criteres. 
5 Les noeuds de ce graphe d' etats representent les etats de l'application ; les 
transitions de ce graphe sont etiquettes par les differents classes d' arguments 
fournis a la methode « process() ». 

Specificites operatoires des plates-formes d' execution : 

10 

Par ailleurs, comme indique en introduction, le bon fonctionnement d'un 
programme depend de la plate- forme d' execution, qui peut implementer ou 
non, convenablement ou non, certaines fonctionnalites. 

15 Afin de prtvoir correctement ou plus finement le comportement d'un 
programme sur une plate-forme ou un ensemble de plates-formes donne, les 
specificites operatoires de ces plates-formes (par exemple le comportement 
des librairies) peuvent etre fournies et exploitees au moment des analyses de 
programme. Bien sur, 1'evaluation des criteres en fonction d' informations 

20 extraites de telles analyses est alors specifique aux plates-formes cibles 
correspondantes. 

Dans le cas d'une analyse par interpretation abstraite, les specificites 
operatoires peuvent etre donnees par des fonctions abstraites qui defmissent la 
25 s&nantique des operations particulieres de ces plates-formes. 

Generalisation aux caracttristiques op6rationnelles des programmes : 

II est important aussi de noter que la procedure dtcrite ci-dessus ne se limite 
30 pas a des criteres booleens et couvre de fait un spectre plus large que celui de 
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la validation d' applications. Plus generalement, cette procedure permet en 
effet de determiner des caracteristiques operationnelles d'un programme. 



Par exemple, le procede selon V invention permet, grace a ses trois etapes, de 
5 determiner les ressources consommees par le programme lors de son 
execution, comme par exemple la quantite totale de memoire allouee. La 
reunion des informations d'acces aux ressources, collectees le long des divers 
chemins d' execution possibles, fournit en effet un encadrement des ressources 
consommees. 

10 

Cette procedure permet aussi notamment de determiner les fonctionnalites de 
la plate-forme d' execution qui sont exploitees par le programme lors de son 
execution. On peut reunir pour cela les fonctionnalites utilisees qui sont 
recensees le long de chacun des chemins d'execution possibles. 

15 

Validation de nouveaux criteres : 



On peut egalement observer que la procedure decrite ci-dessus analyse un 
unique programme donne par rapport a des criteres donnes, criteres 
20 eventuellement specifiques a une unique plate-forme ou classe de plates- 
formes d'execution donnee. 



Toutefois, il n'est pas forcement necessaire de r6-analyser un programme 
quand se pose la question de son adequation a de nouveaux criteres ou a une 
25 nouvelle plate-forme d'execution. II suffit en effet de re-exploiter les 
informations precedemment extraites, et par exemple stockees dans une base 
de donnees. 



Validation et filtrage d'un ensemble de programmes : 

30 
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En reunissant les caracteristiques extraites d'un ensemble de programme, on 
obtient aussi une procedure de validation d'un groupe de programmes destines 
a r£sider ensemble sur une plate-forme donnee. Autrement dit, on peut 
composer des groupes de programmes qui forment un tout coherent par 
5 rapport a des criteres donnes. 

Cette fonctionnalite peut etre utilisee comme filtre sur un serveur 
d' applications. Connaissant les caracteristiques de la plate-forme d' execution 
d'un utilisateur de ce service, les applications incompatibles avec cette plate- 

10 forme sont masquees. L'utilisateur n'a ainsi acces qu'aux applications qui sont 
compatibles avec sa plate- forme d' execution. II est ainsi garanti du bon 
fonctionnement de toute application qu'il voudrait charger. II faut noter qu'il 
n'est pas necessaire de refaire les analyses de programme pour proposer une 
liste d' applications valides a un utilisateur : les resultats d' analyse sont 

15 reutilises ; seuls les calculs correspondant au test de compatibilite par rapport a 
la plate-forme d' execution sont a refaire, s'ils n'ont pas eux aussi deja 6t6 
calculus. 

De preference, F extraction d' informations par analyse statique de programme 
20 n'est effectuee qu'une fois par programme et reutilisee a chaque fois que 
necessaire pour determiner si le programme respecte un ensemble de criteres 
de validite donne. 

Abstraction des informations extraites : 

25 

En pratique, les resultats d'une analyse statique de programme peuvent etre 
assez volumineux et done difficile a stocker. Quand e'est le cas, il peut etre 
avantageux d'abstraire ces resultats pour ne conserver que des informations 
simplifiees. 



30 
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On peut notamment se limiter a un profil d'execution, defini par exemple 
comme T ensemble des fonctionnalites exploitees par le programme et la 
quantite maximale de ressources consommdes au cours d'une execution 
quelconque. Un tel profil, qui ne fait en particulier pas apparaitre la notion de 
5 chemins d' execution, requiert un espace memoire de stockage beaucoup plus 
faible. II est ais^ment compare a un ensemble de fonctionnalites connues 
comme disponibles sur la plate-forme pour les questions d'interoperabilite, un 
ensemble de fonctionnalites declarees utilisables selon des criteres de securite, 
et une borne concernant la consommation des ressources. 

10 

Cet usage du proc^de permet d'elaborer le « diagnostic » d'une application, 
pour une classe de criteres et de plates-formes d' execution particulieres. 

Validation embarquee : 

15 

La determination de caracteristiques operationnelles peut s'effectuer, tout ou 
partie, sur la meme plate-forme qui execute le programme. Ce cas de figure est 
particulierement interessant dans le cas ou les caracteristiques operationnelles 
sont des regies de validity qui expriment le respect par un programme de 
20 criteres particuliers et ou la plate- forme d' execution est un systeme embarque, 
comme par exemple un telephone mobile ou une carte a puce. 

Deux cas particuliers sont a noter. Dans le premier cas, a la fois 1' extraction 
des informations et revaluation des regies de validite sont effectuees sur la 
25 plate-forme d' execution du programme. Dans le second cas, V extraction des 
informations par analyses de programme est effectuee en dehors de la plate- 
forme ; elle est ensuite transmise a la plate-forme, par exemple au moment du 
chargement du programme ; enfin, revaluation des regies de validity a Paide 
des informations transmises est effectuee sur cette meme plate-forme. 



WO 2005/073860 PCT/FR2004/003394 

24 

Comme precedemment mentionne, 1' invention concerne egalement un systeme 
mettant en oeuvre le proc6d6 precedemment decrit pour garantir que des 
applications proposees par un serveur h des clients respectent des criteres de 
validite associes aux plates- formes d' execution de ces applications. 

5 

Ce systdme pourra avantageusement comprendre des moyens de filtrage 
con9us de maniere a ce que, pour tout client desirant acceder aux applications 
pour une certaine plate- forme d' execution, les applications soient filtrees 
conformement a la procedure de verification precedemment d^crite et que 
10 seules les applications qui respectent les criteres de validite pour ladite plate- 
forme soient presentees au client. 

De meme, F invention concerne un systeme d* execution multi applications 
garantissant que les applications respectent des criteres de validite donnes, ce 
15 systeme faisant intervenir un serveur d' analyses d' applications, un serveur de 
validation duplications et une plate-forme d'execution multi applications. 

Ce systeme fait en outre intervenir des moyens permettant d' assurer, avant le 
chargement ou F execution d'une application sur la plate-forme : 

20 

- le respect par cette application desdits criteres conformement au procede 
precedemment decrit, Textraction d'information s'effectuant sur le serveur 
d' analyses d' application tandis que revaluation desdits criteres s'effectue 
sur le serveur de validation d 5 applications, et 

25 

- dans le cas ou un des criteres ne peut pas etre respecte, l'echec du 
chargement ou de 1' execution de F application, la modification de Fetat du 
systeme et Femission d'un signal sonore ou visuel pour avertir de Fechec 
du chargement ou de F execution. 

30 
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Dans ce systeme, le serveur de validation d' applications pourra s'executer sur 
la plate-forme d'ex£cution multi applications, le serveur d'analyses 
d' applications s' executant hors de la plate-forme. Eventuellement, le serveur 
d'analyses d' applications et le serveur de validation d' applications pourront 
5 s'executer sur la plate-forme d'execution multi applications. 
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1. Proceed pour la determination des caracteristiques operationnelles 
d'un programme, 

5 caracterise en ce qu'il comprend une procedure de verification comportant les 
etapes suivantes : 

- une premiere 6tape comportant : 

■ F expression des caracteristiques operationnelles du programme comme 
10 des fonctions portant sur des occurrences ou des sequences 

d'occurrences d'evenements pouvant se produire au cours des 
executions possibles du programme, lesdits 6v6nements pouvant porter 
sur des operations particulieres, sur des valeurs particulieres, en des 
points de programme particuliers et dans des Stats particuliers du 
15 programme ; 

■ la determination d'un degre de precision eventuel avec lequel ces 
caracteristiques doivent etre determinees ; 

■ la determination d'un ensemble eventuel de contextes d'execution 
particuliers dans lesquels le programme sera toujours execute ; 

20 ■ la determination de specificites operatoires Sventuelles d'un ensemble 
de plates-formes sur lesquelles le programme sera execute ; 

- une deuxieme etape d' estimation, par des analyses de programme, et en 
tenant compte dudit degre de precision dventuel, dudit ensemble eventuel 

25 de contextes d'execution particuliers et desdites specificites operatoires 

eventuelles de plates-formes, d' informations concernant la structure du 
programme, les chemins d'execution possibles du programme et les 
valeurs de donnees possibles, en divers points des chemins d'execution et 
sous differentes conditions d'execution, des etats et donnees manipulees 

30 par le programme ; 
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- une troisieme etape de determination desdites caracteristiques 
operationnelles, grace aux informations extraites par lesdites analyses de 
programme, par le calcul desdites fonctions sur les occurrences ou 
sequences particulieres d' occurrences d' operations particulieres, portant 
5 sur des valeurs particulieres, en des points de programme particuliers, dans 

des etats particuliers du programme, pour Fensemble des chemins 
d' execution determine par les analyses. 

2. Proced6 selon la revendication 1, 
10 caracterise en ce que, dans le cas ou le programme est interactif et peut 
dependre d'un nombre indetermine de valeurs dynamiques resultant de cette 
interaction, les contextes d 5 execution sont donnes par une description abstraite 
des suites de donnees possibles representant lesdites valeurs dynamiques. 



15 3. Procede selon la revendication 1, 

caracterise en ce que, dans le cas ou le programme s'insere dans un cadre 
d' execution (« framework »), les analyses statiques prennent aussi en compte 
la semantique de ce cadre d' execution, y compris les eventuelles boucles 
d' interaction implicites du programme. 

20 

4. Procede selon la revendication 1, 
caracterise en ce que certaines desdites operations particulieres (qui, 
accompagnees de contraintes sur les valeurs manipulees, les points 
d' execution, et les etats du programme, forment des ev6nements) sont definies 
25 comme Tune des actions suivantes : appel a une routine donnee, acces a une 
variable donnee, lecture ou ecriture sur un port donne, calcul d'une expression 
arithmetique donnee, fin d'execution du programme ou d'une routine (sur un 
retour normal ou une levee d'exception). 
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5. Procede selon la revendication 1, 

caract6ris£ en ce que certaines desdites analyses statiques sont constitutes par 
des interpretations abstraites du programme, sur des domaines abstraits qui 
peuvent representer notamment des ensembles de valeurs possibles et des 
5 expressions symboliques. 

6. Procede selon la revendication 1, 

caracterise en ce que lesdites informations extraites sont representees a l'aide 
d'une ou plusieurs des structures suivantes : graphe d'etat du programme, 
10 graphe d' heritage, graphe d'appel des routines du programme, graphe de flot 
de controle de chaque routine du programme, structure de boucles et de 
rattrapage d' exceptions, structure de blocs de base (« basic blocks »), 
abstraction de P6tat du programme en un point d' execution. 

15 7. Procede selon la revendication 1, 

caracterise en ce que ladite extraction d' informations ne porte pas sur des 
informations inutiles a la determination des caracteristiques operationnelles, 
tant du point de vue de la quantite d' informations extraites que de la precision 
de ces informations. 

20 

8. Procede selon la revendication 1, 

caracterise en ce que seules les informations majeures parmi lesdites 
informations extraites sont calculees et stockees et en ce que les autres 
informations ne sont calculees que lorsque necessaire pour la determination 
25 desdites caracteristiques operationnelles. 

9. Procede selon la revendication 8, 

caracterise en ce que les informations majeures sont les informations extraites 
aux noeuds d'une decomposition du code des routines en un graphe de blocs de 
30 bases (« basic blocks ») et en ce que les autres informations (dans le corps des 
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blocs de base) sont recalculees par une analyse locale a partir des informations 
stock£es en debut et fin du bloc correspondant. 



10. Procede selon la revendication 1, 
5 caracterise en ce que lesdites caracteristiques operationnelles represented des 
criteres de validite et en ce que ladite determination etablit que le programme 
est valide (parce qu'il respecte chacun desdits criteres) ou invalide (parce 
qu'au moins un desdits criteres peut ne pas etre respecte). 



10 11. Procede selon la revendication 10, 

caracterise en ce que lesdits criteres de validite expriment des regies de 
securite ou d'interoperabilite. 



12. Procede selon la revendication 1, 
15 caracterise en ce que lesdites caracteristiques operationnelles caracterisent les 
ressources qui sont consommees et les fonctionnalites qui sont exploitees par 
le programme lors de son execution et en ce que ladite determination fournit 
un profil d' execution du programme. 



20 13. Procede selon la revendication 1, 

caracterise en ce que le calcul de certaines desdites fonctions associees aux 
caracteristiques operationnelles est effectue au cours desdites analyses 
statiques de programme, des que certaines desdites informations sont extraites. 

25 14. Application du procede selon la revendication 10 au filtrage 

automatique d'un ensemble de programmes par rapport a un ensemble de 
critdres de validite donne, 

caracterise en ce que V extraction d 5 informations par analyse statique de 
programme n'est effectu£e qu'une fois par programme et r^utilisee a chaque 
30 fois que necessaire pour determiner si le programme respecte ledit ensemble 
de criteres de validite. 
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15. Sy steme de distribution d' applications garantissant que les 
applications respectent des criteres de validite assoctes aux plates-formes 
d' execution de ces applications, 

5 caracterise en ce qu'il comprend des moyens de filtrage con9us de maniere a 
ce que, pour tout client d^sirant acceder aux applications pour une certaine 
plate-forme d'execution, les applications soient filtrees par une procedure de 
verification conformement au procede selon Tune des revendications 1 a 12, 
seules les applications qui respectent les criteres de validite pour ladite plate- 
10 forme etant presentees au client. 

16. Systeme d'execution multi applications garantissant que les 
applications respectent des criteres de validite donnes, 

caracterise en ce qu'il comprend : 
15 - un serveur d'analyses d'applications, un serveur de validation 
d' applications et une plate-forme d'execution multi applications, et 
- des moyens permettant d'assurer avant le chargement ou Pexecution d'une 
application sur la plate-forme : 

o le respect par cette application desdits criteres conformement au 
20 procede selon Tune des revendications 1 a 12, 1' extraction 

d' informations s'effectuant sur le serveur d'analyses 
d' applications et 1' evaluation desdits criteres s'effectuant sur le 
serveur de validation d' applications, et 
o dans le cas ou un des criteres peut ne pas etre respecte, Techec du 
25 chargement ou de l'ex^cution de 1' application, la modification de 

l'etat du systeme et remission d'un signal sonore ou visuel pour 
avertir de P£chec du chargement ou de l'execution. 
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17. Systeme selon la revendication 16, 

caracterise en ce que le serveur de validation d' applications s' execute sur la 
plate-forme d' execution multi applications, le serveur d* analyses 
d 9 applications s' executant hors de la plate-forme. 

5 

18. Systeme selon la revendication 16, 

caracterise en ce que le serveur d 5 analyses d' applications et le serveur de 
validation d' applications s'ex6cutent sur la plate- forme d' execution multi 
applications. 



